Setting Target Rotation Times in an IEEE Token Bus Network

The IEEE 802.4 token bus protocol requires each network station to implement a Synchronous (highest priority) message class, and permits a station to implement three lower priority classes: Urgent Asynchronous, Normal Asynchronous, and Time Available. If a station implements the priority option, then the objective is to allocate bandwidth to lower priority frames only after transmission of higher priority frames. Each of the lower three priorities (called access classes) is assigned a target token rotation time (TRT) that limits the amount of time that a station can use to service lower priority traffic. The 802.4 standard does not address how the three Target Rotation Times should be set to achieve any particular priority scheme. Because priority is defined by token cycle time, and since the average user is unlikely to have such detailed knowledge of the network’s operation, it may be difficult for a user to determine which access class is most appropriate for a given message. Users can more easily relate to network throughput (a simple percentage of network capacity) than to token cycle time, so we present an alternative formulation of the problem in which messages are transmitted from an access class as long as network throughput remains below a user-specified threshold. We derive the formulae that transform this priority scheme, based on network throughput limits, into the proper Target Rotation Time settings that the token bus protocol actually requires. Our analytic model is compared against a computer simulation of the token bus protocol and shows close agreement. I . PROTOCOL PERATION HE 802.4 token passing access method [l], [ 2 ] offers four T levels of service called access classes. In order of descending priority they are called Synchronous, Urgent Asynchronous, Normal Asynchronous, and Time Available. The 802.4 standard requires each station to implement the highest priority, or Synchronous, class, and a network variable called the High Priority Token Hold Time (HPTHT) determines the amount of time a station may use to service its Synchronous traffic on each token visitation. Transmission of each message is nonpreemptive, so once a frame begins transmission it will not be aborted. If a station implements the lower three priority classes, then the amount and type of service received depends upon the most recent value of the token circulation time. After a station has serviced its Synchronous traffic, then for each lower priority class in turn the station computes the amount of time elapsed since the token was last received by this station at this access Manuscript received September 4, 1987; revised March 30, 1988. This work was supported by the Institute of Information Technology of the Virginia Center for Innovative Technology. R. M. Gorur was with the Department of Computer Science, University of Virginia, Charlottesville, VA 22903. She is now with Kuck & Associates, Champaign, IL. A. C. Weaver is with the Department of Computer Science, University of Virginia, Charlottesville. VA 22903. IEEE Log Number 8821777. class; if that elapsed time is less than the TRT setting of the access class, then the station is allowed to use the residual time (TRT minus the token circulation time) to service that access class. While the 802.4 standard clearly defines the operation of the protocol and the importance of its operational parameters such as the three TRT’s, it does not specify default values for the TRT’s, nor does it suggest how they should be set. We present an analytic model that calculates the values of the TRT’s that will implement a user-defined priority scheme.